The present invention is directed to computer communications. It particularly concerns what are known as TN3270 servers.
A large installed base of computer equipment employs a communications protocol known as Systems Network Architecture ("SNA"), which specifies the manner in which a host computer, for example, will communicate over a network with a device such as a terminal. At the same time, the Transmission Control Protocol/Internet Protocol ("TCP/IP") has enabled many disparate systems to communicate with each other over a wide variety of physical communications media.
To enable customers to communicate with SNA-compliant systems but take advantage of the large number of TCP/IP links, communications-equipment manufacturers have built communications gateways that translate between the two protocols. FIG. 1 depicts a typical gateway environment.
A user located in a city remote from a host mainframe computer 12 employs his terminal equipment 14, possibly in the form of a personal computer and modem, to gain access to an applications program that runs on the host 12. For this purpose, the terminal employs an Internet path 16--i.e., it employs the TCP/IP communications protocol--to establish a Telnet connection. The Telnet connection is well known to the Internet community and described in its Requests for Comments ("RFCs") 854, 860 and 862. The client terminal 14 is of a type sometimes referred to as a TN3270 emulator. The "TN" refers to the Telnet connection. The "3270" signifies that the connection's data payload, namely, lines of EBCDIC characters and display parameters, are intended to be interpreted in the way that IBM terminals and devices referred to as "3270s" do. (Actually, not all "3270"-device names take the form 327x, but all such devices do use the 3270 data stream.). Such a payload is often referred to as a "3270 data stream."
Such communication requires a TN3270 server such as server 18. Although the host in which the target application is running sometimes performs the TN3270-server process, having it do so is usually considered too prodigal a use of mainframe cycles. So FIG. 1 includes a communications channel 20 between the host 12 and the TN3270 server 18 to indicate that the TN3270 server is embodied in separate hardware.
FIG. 2 depicts a typical sequence in which such communication occurs. Row A represents the client terminal 14's initial connection to the server 18, and row B represents their initial TN3270 negotiation. For this negotiation and all subsequent communications the client and server employ the well-known TCP/IP protocol, salient features of which will now the described by reference to FIG. 3.
FIG. 3's first row represents a typical Internet Protocol datagram. The first part of the datagram is an IP header, which specifies the source and destination nodes and contains various other housekeeping information necessary for transmission from one node to the next. The datagrams' payload consists of TCP segments, each of which begins with a TCP header that specifies the source and destination ports and includes various other information employed, for instance, to guarantee reliable transmission.
The client-terminal process's TCP port number is usually arbitrary, but a TN3270 emulator connects to a server at a specific combination of IP address and TCP port number, from which the server infers that the client thereby connected wishes to use the Telnet protocol. Briefly, Telnet-implementing software typically maps the user's actual physical terminal to a "network virtual terminal," or NVT. An NVT receives and transmits the TCP-segment data as a byte stream. It interprets a byte whose first bit is zero as a symbol from "NVT ASCII," a seven-bit U.S. variant of the ASCII character set that the Internet protocol suite uses to represent letters, numbers, line feeds, carriage returns, etc. A Telnet connection also provides for in-band signaling: if the Telnet port receives an IAC ("Interpret As Command") byte, whose value is 255 (=FF.sub.H), the next byte is ordinarily interpreted as a command, and that next byte may in turn indicate that a further byte or bytes should similarly be interpreted as commands.
When a Telnet client such as terminal 14 connects to a TN3270 server such as server 18, the server employs such commands to negotiate the terms of a TN3270 session. In the literature, one type of initial command used for this purpose is represented by the mnemonic code &lt;IAC DO TN3270E&gt;, where the DO byte (=FD.sub.H) initiates an option negotiation, and the TN3270E byte (=40.sub.H) specifies that the negotiated option is a TN3270 session. (The particular type of TN3270 session used as an example is the type described in RFC 1647. Another type, described in RFC 1576, is initiated by separately negotiating a number of options that individually are not peculiar to TN3270 sessions. RFC 1041 describes yet another type.)
Establishment of a TN3270 session takes the form of a "negotiation" because a Telnet receiver is not in general capable of implementing every requested option. To indicate that it can and will comply with the requested option, a receiver inserts the command sequence &lt;IAC WILL TN3270E&gt;into the data stream that it sends in return, where the WILL byte (=FBR) is what denotes compliance with a requested option.
In many cases, agreement on a requested option initiates further, "suboption" negotiation. Commands in such "subnegotiation" begins with the SB byte (=FA.sub.H) and the code (e.g., TN3270E) for the option whose suboption is being negotiated. Subnegotiation commands end with the SE byte (=FO0.sub.H). In the case of a TN3270E negotiation, subnegotiation may therefore proceed as follows:
Server: IAC SB TN3270E SEND DEVICE-TYPE IAC SE PA1 Client: IAC SB TN3270E DEVICE-TYPE REQUEST IBM-3278-5-E IAC SE PA1 Server: IAC SB TN3270E DEVICE-TYPE IS IBM-3278-5-E IAC SE PA1 Client: IAC SB TN3270E FUNCTIONS REQUEST RESPONSES BIND-IMAGE IAC SE PA1 Server: IAC SB TN3270E FUNCTIONS IS RESPONSES BIND-IMAGE IAC SE
Together, the various mnemonic codes between &lt;IAC SB TN3270E&gt; and &lt;IAC SE&gt; in these lines together represent (1) a request from the server that the client send its service type, (2) the client's specification of its device type, and (3) the server's response that it can handle the specified device type. The subnegotiation may further include the following exchange:
In this exchange the client requests, and the server grants, a suboption referred to as "BIND image." That suboption's purpose will become apparent in due course.
In the particular type of TN3270 session used as the example, all non-command TCP data are interpreted as blocks delimited by the &lt;IAC EOR&gt; sequence, where EOR (End Of Record) represents 19.sub.H, and the start of each block is interpreted as a header, as FIG. 3's second row illustrates.
The server 18 is a node not only on the IP network but also on the SNA network. Communications software in an SNA node performs for each of that node's end users, such as a remote user terminal (in the case of the server node) and (in the case of the host node) the host applications program with which the user terminal is to communicate, a respective process called a logical unit ("LU"). The LU manages the data flow between the associated user and other network entities. Additionally, each node performs a further process, called a physical unit ("PU"), that manages that node equipment's LUs and presents their data to the channel 20. (For reasons not relevant to the present discussion, a given hardware node may actually have more than one PU, but little is lost by considering the special case in which each hardware node runs only a single PU process.) Finally, one of the network nodes performs a further process called a systems services control point ("SSCP"), whose responsibility is the SNA network's overall organization. (Actually, different parts of the network can be organized by SSCPs operating in different nodes, but it simplifies the discussion to consider a single-SSCP network.) The host's Virtual Telecommunication Access Method ("VTAM") software customarily provides this capability.
Now, let us assume that the host's SSCP process has already performed various initial network-organization tasks, such as activating PU and LU processes in each SNA node. For instance, although the terminal 14 typically would not have been connected when the SNA network was initialized, we assume that the SSCP has already activated LUs in the TN3270 server 18 that can represent such a client when it does become attached.
After the network has been initialized, link-level transmissions that support communication among SNA network-accessible units, i.e., among units such as the PUs, the LUs, and the SSCP, occur in basic link units whose format FIG. 4's first row depicts. If they employ the Synchronous Data Link Control ("SDLC") protocol to transmit the SNA-protocol information, the host and server employ FIG. 4's link-header and link-trailer fields to direct the resultant message units to the right data-link stations, frame the message units properly, specify the manner in which link-level operations should interpret them, and detect transmission errors. The data-link station must be specified because the signals that contain messages for the server 18 will also be received by other stations. Each of the SDLC stations may provide a link-level interface for many network-accessible units, and one station may need to forward messages to other link stations, which provide link interfaces for further network-accessible units.
The transmission header in FIG. 4's link unit specifies the origin and destination network-accessible units and provides certain format and sequencing information. The request/response unit contains the payload delivered to the software that handles be SNA operations, and each such payload unit is accompanied by a request/response header, which supports various housekeeping tasks. Much of the time the request/response unit includes segments from the data stream to be forwarded to the terminal (or other ultimate user), but request/response units come in many different types, and most of the different types represent commands or information for the SNA-operations software itself rather than terminal data or commands. For instance, in the course of initializing the network, a SSCP conventionally sends request units of the type known in SNA literature as ACTLU (ACTivate Logical Unit) to a server's PU to activate the logical units to be used for communication with clients that subsequently connect to the server. The PU determines that the message is of the ACTLU (or any other) type by inspecting its request-code field ("RC" in FIG. 4's second row) together with an "RU category" field (not shown) in the request/response header.
We now rejoin the communications scenario that FIG. 2 depicts. A new client--namely, terminal 14--has connected to the server 18 and performed a TN3270E negotiation. The server must select one of the activated LUs to mediate communications between the client terminal 14 and the host application with which it is to communicate.
But the LU selection cannot the made at random. Different clients have different capabilities, a communications session's ground rules depend on those capabilities, and host processes will observe different sets of ground rules when they communicate with different server LUs. A typical arrangement requires that the server be able to infer what those ground rules are from the name that the SSCP assigns the LU, so the LU names that the SSCP communicates to the server's PU during initialization establish different pools of LUs having respective session-parameter sets. That is, a TN3270 server conventionally must maintain a list of which LUs belong to which pools. And to select the right LU for the right client, it must incorporate a table that associates different device types with different ones of the pools into which the activated LUs can fall.
The server bases its LU selection on this information, and its PU process sends the host SSCP what is known in SNA literature as a Notify message, as FIG. 2's row C indicates, to indicate that the selected LU has been enabled. In response, the host SSCP process sends the just-enabled LU a data message whose payload is a logon greeting that the terminal 14 is to display to the human user. (Those skilled in the art will recognize that the SNA protocol requires other responses, too, but we omit them to avoid obscuring by excessive detail the facts central to the present discussion.) In 3270 parlance, this greeting is referred to as the USS10 message, and FIG. 2's row D uses that terminology. In contrast to row C's "Notify" legend, which specifies the SNA message type, the "USS10" legend in row D specifies an SNA message's data contents.
When a user has logged on, the host LU representing the applications program to which the user is to be given access initiates an LU--LU session with the terminal-representing LU by sending an SNA message of the BIND type. The contents of a BIND message establish the ground rules for an LU--LU session.
Although the whole purpose of the TN3270 session is for the payloads of various messages in this LU--LU session to be forwarded in TCP segments to the client terminal 14, the BIND message's contents relate primarily to parameters that the SNA protocol employs in carrying that payload between the host and server, so a 3270 terminal does not necessarily require access to the data that the BIND message contains. Still, certain clients can profitably employ information contained in the BIND message, and this is particularly true if the client is a printer such as printer 22 rather than a terminal.
If the client has been designed to take advantage of this information, it will have so notified the server during the TN3270 negotiation. This is the purpose of the "BIND-image" subnegotiation mentioned above. If the client has negotiated this option, the server forwards the BIND message's contents to the client. The "BIND image" notation in FIG. 2's row E represents transmitting this information as Telnet data. The contents of the TN3270 header's data-type field (FIG. 3's third row) destinguish that information from the normal 3270 data stream. (The other third-row fields are not particularly relevant to the present discussion and will not be described here.)
Now, some symbols (i.e., byte values) used in the BIND-message contents are intended to be interpreted differently from the same symbols in the normal 3270 data stream. In the literature, data intended to be so interpreted are often referred to as SCS (SNA character set) as opposed to the 3270 data stream. Terminals that have negotiated the BIND-image option therefore interpret the BIND image as SCS symbols. However, since such terminals are made aware of the occurrence of the LU--LU bind, they recognize the USS10 message as originating in the SSCP as opposed to the host application, so they conventionally interpret that message as SCS symbols, too. A consequence is that TN3270 servers have conventionally had to translate the USS10 text from a TN3270 data stream to SCS before forwarding it to clients that request a BIND image. This is the reason for the "possible translation" notation in FIG. 2's row D.
After all of these preliminaries, the TN3270 session proceeds, as FIG. 2's row E indicates.